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PROCEDE ET TERMINAL DB CX)MMDNIC!ATION EMTRE DETXK XmiTES 

La prSsente Invention conceme les temninaux infomnatiques pennettant 
des actlvlt6s de type navigation sur r§seau et offrant aux utilisateurs la 
5 possibility d'installer des applications. 

De tels tenninaux peuvent notamment §tre des t^i^phones utilisant le 
protocole d'appllcation sans fil (WAP, "wireless application protocol"), des 
ordinateurs de bureau, des ordlnateurs portables ou des assistants num^riques 
personnels (PDA, "personal digital assistant"), lis ont en commun la 
10 caracteristique d'etre relies a un reseau de donn^es num^rique, qui dans 
beaucoup de cas pratiques est un reseau fonctionnant selon le protocole IP 
("Internet protocol"), notamment I'lntemet. 

Dans le cas d'un terminal "fermS" (exemple: un Minitel), les 
applications pr^sentes sur le terminal sent connues et ne peuvent pas §tre 
15 chang^es au cours de la vie du terminal. 

L'ouverture d'un terminal fait r^f^rence d la possibility offerte d 
I'utilisateur d'instailer, et souvent de tyiycharger, de nouvelles applications 
destinies d §tre ex^cut^es par le terminal lul-m§me. Des exemples de 
terminaux "ouverts". Integrant cette posslbllite, sent: 

20 • les tyi^phones d tdiychargement d'applications. par exemple de type 
Java MIDP ("Mobile Infonnatlon Device Profile", Sun Microsystems, Inc.); 

• les navigateurs possedant des fonctionnalites dites de scripting, par 
exemple de type WMLScript (voir "WAP WMLScript Language 
Specification", version 1.1, WAP Forum, novembre 2001) ou ECMAScript 

25 (aussi appeiy JavaScript, voir "ECMAScript Language Specification", 

Standard ECMA-262, 3° Edition, decembre 1999), ou accuelllant des 
applets; 

• la plupart des PDA, fonctionnant sous les systSmes d'exploitation 
PalmOS, WindowsCE, Symbian etc.; 

30 . • les ordinateurs de bureau ou portables. 
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Les terminaux "semi-ouverts" sont les terminaux ouverts dont certalnes 
fonctlonnalit§s ne sont pas directement accessil?les aux applications Install6es 
par I'utilisateur ou t616cliarg6es. Par exennple, dans un termlnai dont la seule 
"ouverture" est ECMAScript, les applications tel6chargees ne peuvent pas 

5 acc6der d toutes les fonctionnalit6s du r^seau (par example, 6mettre des 
paquets IP n'ob6lssant pas aux formats des protocoles de transport les plus 
courants, d savoir TCP ("transmission control protocol") ou UDP ("user 
datagram protocol")). Ces fonctlonnarrt6s peuvent §tre accessibles de fagon 
indirecte et contr6l6e. Par exemple. une fonctlon ECMAScript peut commander 

10 le chargement d'une page via HTTP ("hypertext transfer protocol"),, ce qui 
utilise le rSseau mais d'une fa^on contrdlee. 

Dans des temiinaux "semi-ouverts", II y a coexistence: 

• d'applicatlons consld6r6es comme "de confiance", par exemple parce 
qu'elles ont 6t6 install6es en usine par le fabricant du terminal, ou bien du 

15 fait de la garantle procur6e par des moyens tels que la signature 

^lectronique de Tapplicatlon etc.; . . 

• et d'autres applications qui peuvent etre instances sur le terminal par 
I'utilisateur lui-m§me, d son libre choix, mais n'accedent pas aux m§mes 
droits que les applications de confiance. 

20 Les terminaux "compl6tement ouverts", par opposition, sont les 

terminaux ouverts dans lesquels toutes les fonctionnalit6s sont accessibles aux 
applications t6l§charg§es. La notion d'ouverture d'un temiinal depend dans 
une large mesure du contexte dans lequel on se place. Par exemple, 
diff6rentes couches du modele OSI (lien / r6seau / session / transport / ...) 

25 peuvent avoir diff^rents degres d'ouverture. 

On s'int6resse id aux fonctionnallt6s observables ^ distance, depute un 
serveur, c'est-ii-dire aux fonctionnalit6s de r6seau. Dans ce cadre, le caractdre 
"semi-ouvert" d'un terminal implique g6n§ralement que des droits d'ex6cutlon 
observables § distance, accessibles aux applications de confiance, ne sont pas 
30 accessibles aux applications sans confiance (par exemple, le droit d'emettre 
des requites autres que HTTP sur un reseau IP). Ceci permet d un serveur de 



wo 2004/066580 PCT/FR2003/003181 

-3- 

distinguer, parmi les requetes qui lul arrivent, celles qui proviennent 
d'applications de confiance et celles qui proviennent d'autres applications. II 
peut en particulier distinguer les requites provenant d'applications 
t6l6charg6es des requetes provenant d'applications pr§sentes dhs I'orlgine 
5 dans le terminal. 

Dans les temiinaux ouverts, 11 faut tenir compte de la posslblllt6 qu'un 
programme se comporte de fagon trompeuse vis-S-vis de rutillsateur (cheval 
de Troie). Ainsi, rien ne peut garantir ^ un serveur qu'une requ§te provient bien 
de rutilisateur, et non d'un programme ayant slmul6 I'accord de rutillsateur au 
10 niveau du reseau. Ce risque ruine la confiance que le serveur peut avoir dans 
les donnees qu'il regoit d'un client. L'hypothese selon laquelle les requ§tes 
adress6es au serveur refletent les actions de I'utllisateur n'est pas raisonnable 
si un cheval de Troie a la possibility de les envoyer d la place de I'utilisateur. 

On fera done dans la suite une distinction entre les applications 
15 presentes sur le terminal: 

• applications de confiance: le serveur est pr§t d faire l'hypothese que ces 
applications ne sont pas des chevaux de Troie. Par exemple, le 
navigateur WAP d'un t616phone WAP peut constltuer une application de 
confiance. Un autre exemple peut §tre une application Java MIDP 

20 t^l^charg^e avec signature; 

• applications sans confiance: le serveur considfere que ces applications 
peuvent §tre des chevaux de Troie. Par exemple, des applications Java 
MIDP t61echarg§es sans signature sur un terminal peuvent §tre des 
applications, sans confiance. 

25 La reponse classique au risque de cheval de Troie est de llmiter les 

capacites des applications sans confiance. 

La limitation de remission des trames depuis les termlnaux semi- 
ouverts se fait g6n6ralement de fagon extr§mement stricte. Seules les 
applications systSme (fournles avec le syst6me d'exploitation du terminal) sont 
30 autorlsees d ^mettre certaines trames. 



wo 2004/066580 



PCT/FR2003/003181 



II devient done impossible d une application t6l6charg6e (avec ou sans 
confiance) d'emettre des frames vers un serveur, m§me si cette application 
dispose par ailleurs de moyens d'obtenir la confiance du sen/eur du fait du 
contenu des trames qu'elle 6met (exemple: emission de donn6es sign6es) ou 
5 du fait de ses caracteristiques (exemple: signature associ6e a son contenu). 

Un but de la pr6sente Invention est d'offrir une difference de. capacity 
d'envoi de requ§tes d'un nouveau type entre applications "de confiance" et 
applications "sans confiance", qui sort flexible pour les applications et puisse 
neanmoins §tre identifi^e par le serveur destinataire. La notion de confiance 
10 peut s'appuyer sur des entires varies (signature, type d'echange, URL depuis 
laquelle Tapplication a et6 tel^charg^e, etc.)- 

L'Invention propose ainsi un proc6d6 de communication entre une 
premiere unit6 et une seconde unit6 par I'intennddlaire d'un r^seau de 
telecommunication, dans lequel la premiere unit6 comporte des applications 

15 appartenant respectivement S une premiere famllle et d une seconde famille 
presentant a priori un degr§ de confiance plus faible que la premiere famille. 
Selon un aspect de I'invention, on contraint chaque requite issue d'une 
application de la seconde famille, 6mise sur le reseau ^ destination de la 
seconde unit6, a inclure un marquage associe d la seconde famille 

20 d'applicatlons. Selon un autre aspect de I'invention, on contraint chaque 
requite Issue d'une application de la seconde famille, 6mlse sur le riseau h 
destination de la seconde unit6, a ne pas inclure un marquage assocte d la 
premiere famille, ledit marquage 6tant Indus dans certalnes au moins des 
requites imises sur le riseau et Issues d'applicatlons de la premiire famille. 

25 L'Invention propose aussi un temnlnal de communication, comprenant des 
moyens de mise en oeuvre d'un tel proc6d6 en tant que premiire uniti. 

Le procidi pemiet a certalnes applications particulieres ("de 
confiance") s'exicutant dans la premiire unite d'imettre des trames d 
I'attention d'une seconde uniti, giniralement un serveur distant, avec la 
30 garantie pour cette seconde uniti de I'origine flable de ces trames. L'inclusion 
obligatoire du marquage pour les applications a priori sans confiance de la 
seconde famille (ou symetrlquement son interdiction) distingue, d I'imlsslon, 
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ies trames 6mlses par ces applications a priori sans confiance par rapport d 
celles 6mises par des applications de confiance. Cecl pemiet au serveur de 
faire le tri entre les requ§tes acceptables, en lesquelles il a confiance, et celles 
qu'il doit rejeter. 

II convient que le marquage appllqu6 soit compl6tement "6tanche", 
c'est-a-dire qu'll ne soit pas possible pour une application a priori sans 
confiance de court-circuiter les centrales effectues d un certain niveau (par 
exemple: fonctions de requ§tes HTTP), en attaquant les couches plus basses 
(par exemple: requete d'une connexion TCP). 

Dans une realisation du proc6d6, on contraint le marquage, Indus dans 
une requ§te emise sur le r§seau et issue d'une application de la seconde 
famille, d inclure une indication de la nature et/ou de I'origlne de ladlte 
application de la seconde famille. Cette indication conslste par exemple en des 
donn6es relatives d la certification de la signature d'une application sign6e, ou 
encore § I'adresse de t§i§chargement d'une application t6l6charg§e par 
I'intermediaire du reseau. Elle peut §tre utilisee par I'unit^ distante pour evaluer 
si elle peut faire confiance a I'application qui ne pouvait a priori qu'§tre jugee 
sans confiance par la premiere unit6. 

Grdce au procSdd, des termlnaux supportant le t6l6chargement des 
applications peuvent 6changer des donn6es en toute confiance avec un 
serveur, malgr6 les risques inherents a ces capacit6s de t6lechargement 
("ouverture" du temiinal). Le precede procure ainsi une protection simple et 
efficace centre ies chevaux de Troie. 

D'autres particuiarites et avantages de la pr6sente Invention 
apparaTtront dans la description ci-apr&s d'exemples de realisation non 
limitatifs, en reference au dessin annex6, dans lequel la figure unique est un 
schema d'un systeme mettant en ceuvre i'invention. 

On cherche § permettre i une unit6 distante telle qu'un serveur 1 
d'obtenir de fagon sOre et souple la confiance dans des requites regues sur un 
reseau de telecommunication R en provenance d'un tenninal seml-ouvert 2. Ce 
temiinal h6berge d'une part des applications de confiance 3, comme par 
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exemple un navigateur web, et d'autre part des applications a priori sans 
confiance 4, notamment des applications que Tutillsateur du temnlnal a 
t^lechargees par I'lnterm^dlaire du r^seau R. 

Les applications a priori sans confiance 4 sont contralntes quant aux 
5 trames ou requites qu'elles peuvent 6mettre sur le reseau R, ce qui, dans le 
schema, est symbolist par une couche de contrSle 5 faisant partie des 
ressources 6 d'accSs au reseau dont est equips le terminal 2. 

La couche de contrfile 5 verifie que certaines propri6t6s sont rempiies 
par les trames ^mises par les applications a priori sans confiance 4. Si ces 
10 propri6t6s sont rempiies, la couche de contr6le laisse passer les trames. Sinon, 
elle peut soft ne pas les laisser passer vers le reseau R et en pr6venir 
I'application 4 qui les a 6mises, soft modifier les trames pour les conformer aux 
contralntes des applications a priori «ans confiance. Dans ce dernier cas, la 
trame perd sa credibility aux yeux du serveur 1, qui pourra ne pas I'explofter. 

. 15 Les contralntes precft^es se rapportent d la pr6sence ou non d'un 

marquage specifique dans les requites 6mises sur le reseau R depuls 
certaines des applications. 

Dans un premier mode de realisation de {'invention, la couche de 
contr6le 5 impose aux requetes issues des applications a priori sans confiance 
20 4 d'inclure un marquage associS d cette famille d'applications. Une application 
de confiance 3 acc6de a des fonctionnalft6s qui lul pemiettent de contoumer la 
couche de contrite 5 et d'6mettre des requites non marqu6es. En revanche, 
les ressources 6 d'acces au reseau ne mettent pas ces fonctionnalit^s d 
.disposttion des applications a priori sans confiance 4. 

25 Dans un exemple iilustrant ce premier mode de realisation, le terminal 

2 (par exemple un telephone mobile) dispose d'une machine virtuelle Java, 
pouvant conrespondre au module 6 sur la figure. La machine virtuelle penmet 
d'exicuter des applications tilichargies ecrites dans ie langage de 
programmation Java mis au point par la sociiti Sun Microsystems, Inc. Toutes 

30 les instructions du langage Java sont exScuties par la machine virtuelle, qui 
fait appel aux fonctlons systime apris un certain contrSle. Pour les 
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applications Java, on est bien dans un environnement semi-ouvert puisqu'll nV 
a pas d'appel sans contrdle aux fonctions systdme. Ce terminal 2 n'est capable 
de tel^charger que du code Java, aucun autre type d'application ne pouvant y 
htre install^ par rutilisateur. 
5 L'application a priori sans conflance 4 est alors 6crite en langage Java. 

Dans cet exemple, les protocoles mis en jeu pour les ^changes du 
tenpinal 2 sur le r6seau R sont les protocoles HTTP (RFC 1945 ("Request For 
Comments"), publlee en mal 1996 par I'lETF ("Internet Engineering Task 
Force")). TCP (RFC 793, IETF, septembre 1981) et IP (RFC 79 1, IETF. 

10 septembre 1981). 

Le service est h^berge par un serveur HTTP 1 qui stocke du contenu 
appartenant ^ I'utilisateur. II dolt s'assurer du fait qu'une requ§te (demandant 
par exemple I'effacement de tous les ficliiers) provient bien de rutilisateur. et 
non d'un programme Java mal lntentionn6. Ce service est bien entendu un 

15 exemple. n'importe quel autre service pouvant §tre feire appel a cette 
technique (commerce §lectronlque. publication de documents, messagerie, 
etc.). 

Le marquage peut §tre Indus dans le champ d'en-tete "User-Agent" 
des requStes HTTP (cf. section 10.15 de la RFC 1945 precitee). II consiste en 

20 une chaTne sp6clflque telle que "Application sans confiance: VM 
Java 1.2" qui Indkjue par sa pr6sence que la requite n'est pas en 
provenance d'une application a priori de confiance. Cette chaTne peut §tre d6j§ 
pr6sente dans la requite produlte par l'application 4, auquel cas la couche de 
controle 5 de la machine virtuelle 6 se contente de v6rifier sa presence. Sinon, 

25 cette couche 5 I'insere pour que la requete soit convenablement marqu6e. 

L'6tanch§it6 du marquage appllqu6 par la machine virtuelle 6 resulte 
de ce qu'll n'est pas possible ^ une application a priori sans confiance 4 
d'imettre sur le r6seau R des requites HTTP ne contenant pas cette chaTne 
spicifique. En partlculler, l'application 4 ne peut pas avoir accis au riseau R 
30 en se branchant sur une couche protocolaire plus basse que HTTP, 
notamment aux sockets TCP. Le marquage est implimenti directement dans 
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la machine virtuelle 6 dans laquelle I'application a priori sans confiance est 
obligee de s'executer et qu'elle ne peut 6vlter d'aucune manure. 

Le serveur 1 peut ainsi trier, parmi les requites qui lul arrivent, ceiles 
qui proviennent d'appllcations a priori sans confiance 4 et ceiles qui 
5 proviennent d'applicatfons de confiance 3 telles qu'un navigateur web. 

II existe des applications qui ne sont de confiance que pour certains 
sites. Par exemple. une applet Java est g6neralement consideree comme de 
confiance par le site depuls lequel elle a 6te t6l§charg6e. mais non par d'autres 
sites. Le marquage ne sera done pas toujours n6cessalre dans les requdtes 

10 destln6es a ce site de t6l6chargement. En d'autres temies, la machine virtuelle 
6 peut imposer le marquage aux requ§tes Issues d'une telle applet et 6mises 
vers un site autre que celui d'oil elle a 6t6 t6l6charg6e et lalsser I'applet libre 
d'inciure ou non le marquage dans les requ§tes qu'elle 6met vers son site 
d'origine. Une autre possibHit6 est d'Imposer le marquage S toute requ§te 

15 6mise par une telle applet, quelle qu'en soit la destination. 

Une alternative ou un compl6ment au marquage des requ§tes sans 
confiance peut §tre I'lnterdiction de certaines de ces requ§tes. Par exemple, 
pour des applications sans confiance t6l6charg6es depuls un serveur donn6. 
les requ§tes directes d destination de serveurs diff6rents pounalent §tre 
20 interdites. Les requites d destination du serveur d*origlne resteraient possibles, 
avec le marquage. 

Dans une realisation avantageuse, on adjoint obligatolrement au 
marquage une indication de la nature et/ou de I'origlne de I'application a priori 
sans confiance 4 dont elle est issue. 

25 Cette application a priori sans confiance 4 peut etre signee. Les 

requStes qui en proviennent seront alors marquees avec un en-tete contenant 
. au moins I'un des Elements sulvants, susceptibles de fonder la confiance du 
serveur distant dans cette application: 

• le certlficat du signataire de I'application, ou un condense de ce certfflcat; 
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• le certificat de la chaTne de certification d'ou le certificat du signataire de 
I'application est issu, ou un condense de ce. certificat; 

• une chaTne specialement incluse dans le code de I'application i cet effet; 

• un ^Idment variable identifiant i'application de maniSre dynamique. 

5 Une telle realisation de Tinvention est notamment applicable dans le 

cas d'une application Java signSe par un certificat. 

Dans ce cas, la machine virtuelle 6 dolt verifier la signature de 
I'application Java avant remission des requ§tes. En pratique, cette verification 
a lieu avant I'executlon de I'application 4. 

10 Le marquage peut alors consister en I'ajout d'une chaTne specifique 

dans l'en-t§te HTTP, comme par exemple: "Contenu de conf iance - 
Application sign^e par <c>" oil <c> est la valeur du certificat du 
signataire de i'application, ou un condense de celui-ci. Cet en-tSte indlque par 
sa presertce que la requ§te est en provenance directe d'un utilisateur. et a- §16 

15 creSe par un iogiciei de provenance connue. 

De cette fa9on, si le serveur 1 accorde sa confiance au d^tenteur des 
clefs privies associees au certificat <c>, ie serveur est garanti que les 
requ§tes marquees de cet en-t§te specifique correspondent bien d un accord 
effectif de I'utilisateur. La contrainte de marquage evKe que rapplication pulsse, 
20 auprSs du serveur, se reclamer d'un signataire autre que le signataire r§el. 

Dans le cas des applet Java teiechargees. la machine virtuelle 6 est 
capable d'identifier I'adresse de teiechargement de I'application. Elle peut ainsi 
contraindre la requ§te issue d'une telle applet, a priori sans confiance, d'inclure 
son adresse de teiechargement ou des donn^es qui dependent de cette 
25 adresse. 

Dans un autre mode de realisation de I'invention, la syntaxe du 
marquage est inversee: la couche de controle 5 impose aux requdtes issues 
des applications a priori sans confiance 4 de ne pas inclure un marquage 
specifique aux applications de confiance 3. 
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Pour se manifester comme etant de confiance pour un serveur 1, une 
application 3 inclut alors le marquage dans la requ§te qu'elle lui adresse. La 
couche de contr^le 5 s'assure que ce marquage est absent de chaque requete 
issue d'une application a priori sans confiance 4, le caract^re sans confiance 
pouvant comme pr6c6demment §tre appr§ci6 en fonction du site destinataire 
de la requ§te. Si le marquage est pr6sent dans une requete issue d'une 
application a priori sans confiance 4. la requite n'est pas 6mise telle quelle: le 
marquage est enlev6 par la couche de contrSle 5 et celle-cl peut 6mettre ou 
non la requ§te "d6marqu§e" sur le reseau R et pr6venir ou non I'application 4. 

La convention employee pour la syntaxe du marquage doit 
naturellement dtre commune au temiinal et au serveur, et connue des deux 
avant la transaction. 
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REVENDIC ATIONS 

1. Proc6de de communication entre une premidre unite (2) et une 

seconde unite (1) par Tintermediaire d'un reseau de telecommunication (R), 
dans lequel la premiere unite comporte des applications (3, 4) appartenant 
5 respectivement a une premiere famille et a une seconde famille presentant a 
priori un degre de confiance plus falble que la premiere famille, caracterise en 
ce qu'on contraint chaque requete issue d'une application (4) de la seconde 
famille, Smise sur le reseau a destination de la seconde unite, a inclure un 
marquage assocIS S la seconde famille d'applications. 

10 . 2. Proc§d§ selon la revendlcatlon 1, dans lequel ledit marquage est 

inclus dans chaque requete emise sur le reseau (R) et Issue d'une application 
de la seconde famille (4). 

3. Proc6d6 selon la revendication 1 ou 2, dans lequel on contraint le 
marquage, inclus dans une requite emise sur le reseau (R) et issue d'une 

15 application (4) de la seconde famille, d inclure une indication de la nature et/ou 
de I'origine de ladite application de la seconde famille. 

4. Precede selon la revendication 3, dans lequel, ladite application (4) 
de la seconde famille etant signee, on contraint le marquage, inclus dans les 
requetes qui en sont issues, a inclure des donnees relatives a la certification de 

20 la signature. 

5. Precede selon la revendication 3 ou 4, dans lequel, ladite application 
(4) de la seconde famille ayant ete telecharg§e par I'lntenn6diaire du r6seau 
(R) depuls une adresse de tel§chargement, on contraint le marquage, inclus 
dans les requStes qui en sont Issues, d inclure des donnees relatives d 

25 Tadresse de t§lechargement de rappllcation. 
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6. Precede de communication entre une premiere unite (2) et une 
seconde unit§ (1) par I'intermSdiaire d*un r^s^au de telecommunication (R), 
dans iequel la premiere unit§ comporte des applications (3,4) appartenant 
respectivement a una premiere famille et a une seconde famille presentant a 

5 priori un degr6 de confiance plus faible que la premiere famille, caracterise en 
ce qu'on contraint chaque requete issue d'une application (4) de la seconde 
famille, emise sur le reseau a destination de la seconde unite, a ne. pas inclure 
un marquage associe a la premiere famille, ledit marquage etant Indus dans 
certaines au moins des requ§tes Smises sur le reseau et issues d'applications 

10 (3) de la premiere famille. 

7. Precede selon Tune quelconque des revendications pr^cedentes, 
dans Iequel la seconde unite (1) examine si le marquage est present dans une 
requete regue sur le reseau (R) depuis la premiere unite (2), pour evaluer un 
degre.de confiance d attacher a ladite requete. 

15 8. Precede selon la revendication 7, dans Iequel, lorsque le marquage 

est present dans ladite requete, la seconde unite (1) examine en outre des 
donnees incluses dans ce marquage, pour evaluer un degre de confiance e 
attacher a ladite requete. 

9. Procede selon la revendication 8, dans Iequel lesdites donnees 
20 examinees par la seconde unite (1) comprennent des donn6es relatives a la 

certification d'une signature de rapplication dont est issue la requete. 

10. Precede selon la revendication 8, dans Iequel lesdites donnees 
examinees par la seconde unite (1) comprennent des donnees relatives e une 
adresse de teiechargement de Tapplication dont est issue la requete. 

25 11. Precede seion Tune quelconque des revendications precedentes, 
dans Iequel les requetes comprennent des requetes HTTP, et le marquage est 
insere dans les en-tetes des requetes HTTP. 
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12. ProcSd^ selon I'une quelconque des revendications pr^cedentes, 
dans lequel ia contrainte relative au marquage est contrdide par une couche 
logicielle (5) appartenant i une machine virtuelle (6) dont est pourvue la 
premiere unitd (2), les applications (4) de la seconde famille ne pouvant 

5 acc6der au r6seau (R) qu'a travers la machine virtuelle et ladite couche 
logicielle. 

13. Proc6d§ selon la revendication 12, dans lequel la machine virtuelle 
(6) est une machine virtuelle Java. 



10 



14. Terminal de communication (2), comprenant des moyens de mise en 

ceuvre d'un proced§ selon I'une quelconque des revendications prec^dentes en 
tant que premiere unit6. 
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